1) CONCEP.TEX[CLS,LSP] and 2) CONCEP.17[CLS,LSP]	7-29-87 11:24	pages 1,1

**** File 1) CONCEP.TEX[CLS,LSP]/1P/11L
1)	Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon.
1)	Contributors to this document include Patrick Dussud, Kenneth Kahn,\break
**** File 2) CONCEP.17[CLS,LSP]/1P/11L
2)	Richard P. Gabriel, Sonya Keene, Gregor Kiczales, and David A. Moon.
2)	Contributors to this document include Patrick Dussud, Kenneth Kahn,\break
***************


**** File 1) CONCEP.TEX[CLS,LSP]/1P/597L
1)	\beginSection{Integrating Types and Classes} 
1)	The \CLOS\ maps the Common Lisp type space into the space of classes.
1)	Every class that has a name has a corresponding type with the same 
1)	name.  {\bf defclass} and {\bf defstruct} define both types and classes.  
1)	The name of every class is a valid type specifier.   In addition, every
1)	class object is a valid type specifier.  Thus the expression {\tt (typep 
1)	{\it object class\/})} evaluates to true if the class of {\it object\/} 
1)	is {\it class\/} itself or a subclass of {\it class}.  The evaluation of
1)	the expression {\tt (subtypep {\it class1 class2\/})} returns the
1)	values {\bf t t} if {\it class1\/} is a subclass of {\it class2\/} or if they
1)	are the same class; otherwise it returns the values {\bf nil t}. 
1)	Many but not all of the predefined Common Lisp type specifiers have a
1)	corresponding class with the same name as the type.  For 
1)	example, the type {\bf array} has a corresponding class named {\bf array}.  
1)	A class that corresponds to a predefined Common Lisp type is called a
1)	{\bit standard type class\/}.  Each standard type class has the class
1)	{\bf standard-type-class} as a metaclass.  It is not allowed to make an
1)	instance of a standard type class with {\bf make-instance} nor to include
1)	a standard type class as a superclass of a class.
1)	The purpose for specifying that many of the standard Common Lisp types
1)	have a corresponding class is to allow users to write methods that
1)	discriminate on these types.  The hierarchical relationships among   
1)	the Common Lisp types are maintained by the classes corresponding to  
1)	those types.   Thus the existing type hierarchy is used for determining  
1)	the class precedence lists for each standard type class.    
1)	Method selection requires that a class precedence list can be
1)	determined for each class, ordering the class and its superclasses from 
1)	most to least specific.  In some cases, {\it Common Lisp:  the 
1)	Language\/} does not specify a subtype/supertype relationship for two 
1)	supertypes of a given type.   For example, {\bf null} is a subtype of
1)	{\bf symbol} and {\bf list}, but {\it Common Lisp:  the Language\/} does
1)	not specify whether {\bf symbol} is more or less specific than {\bf
1)	list}.  The \CLOS\ specification defines those relationships for all
1)	standard type classes. 
1)	The following table lists the set of standard type classes required by
1)	\CLOS\.  The superclasses of each standard type class are presented in
1)	order from most specific to most general: 
1)	    STANDARD TYPE CLASS		SUPERCLASSES 
  1) CONCEP.TEX[CLS,LSP] and 2) CONCEP.17[CLS,LSP]	7-29-87 11:24	pages 1,1

1)	    array			t
1)	    bit-vector			vector, array, sequence, t
1)	    character			t
1)	    complex			number, t
1)	    cons			sequence, t
1)	    float			number, t
1)	    integer			rational, number, t
1)	    list			cons, sequence, t 
1)	    null			list, cons, symbol, sequence, t
1)	    number			t
1)	    ratio			rational, number, t
1)	    rational			number, t
1)	    sequence			t
1)	    string			vector, array, sequence, t
1)	    symbol			t
1)	    t
1)	    vector			array, sequence, t
1)	 
1)	Note that instances of standard classes are type disjoint with all other
1)	types.
1)	Individual implementations can allow other type specifiers to have a 
1)	corresponding class.  Also individual implementations can add additional
1)	subclass relationships as long as they do not violate {\it Common Lisp:
1)	the Language\/}.  
1)	Creating a type by means of {\bf defstruct} also creates a class in the
1)	space of Common Lisp classes.  Such a class is an instance of {\bf
1)	structure-class} and a direct subclass of the class that corresponds to
1)	the included structure, if any.
1)	No type specifier that is a list, such as {\tt (vector double-float 
1)	100)}, has a corresponding class.   No type defined by {\bf deftype} has 
1)	a corresponding class. 
1)	For a discussion on some of the design decisions underlying this aspect
1)	of \CLOS\, see the section ``Design Theories of the Integration of Types
1)	and Classes''.
1)	\endSection%{Integrating Types and Classes}
**** File 2) CONCEP.17[CLS,LSP]/1P/597L
2)	\beginSection{Integrating Types and Classes}
2)	The \CLOS\ maps the Common Lisp type space into the space of classes.
2)	Many but not all of the predefined Common Lisp type specifiers have a
2)	class associated with them that has the same name as the type.  For
2)	example, an array is of type {\bf array} and of class {\bf array}.
2)	A class that corresponds to a predefined Common Lisp type is
2)	called a {\bit standard type class\/}.  Each standard type class has the
2)	class {\bf standard-type-class} as a metaclass.   Users can write methods that
2)	discriminate on any primitive Common Lisp type that has a corresponding class.
2)	However, it is not allowed to make an instance of a standard type class 
2)	with {\bf make-instance} or to include a standard type class as a 
2)	superclass of a class.  
  1) CONCEP.TEX[CLS,LSP] and 2) CONCEP.17[CLS,LSP]	7-29-87 11:24	pages 1,1

2)	%Figure~1-1 lists the standard type classes.
2)	%Figure~1-2 displays part of the space of standard type classes.
2)	%[Figure 1-1, standard type classes, should go here.
2)	%Caption:  Standard type classes.  These classes correspond to predefined
2)	%Common Lisp types.  The class nil has no instances.]
2)	Which Common Lisp types will have corresponding classes is still under
2)	discussion.
2)	Creating a type by means of {\bf defstruct} creates a class in the
2)	space of Common Lisp classes.  Such a class is an instance of {\bf
2)	structure-class} and a direct subclass of the class that corresponds
2)	to the type given as its {\bf :includes} argument, if any.
2)	Every class that has a name has a corresponding type with the same
2)	name.  In addition, every class object is a valid type specifier.
2)	Thus the expression {\tt (typep {\it object class\/})} evaluates to
2)	true if the class of {\it object\/} is {\it class\/} itself or a
2)	subclass of {\it class}.  The evaluation of the expression {\tt
2)	(subtypep {\it class1 class2\/})} returns the values {\bf t t} if {\it
2)	class1\/} is a subclass of {\it class2\/} or if they are the same
2)	class; otherwise it returns the values {\bf nil t}.
2)	\endSection%{Integrating Types and Classes}
***************